kermit.columbia.edu/kermit.columbia.edu.tar/kermit.columbia.edu/newsgroups/misc.19950528-19950726/[e-mail]_Mon Jun 26 23:12:10 1995.msg

Internet Message Format | 1995-07-31 | 4KB

Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA12372
  (5.65c+CU/IDA-1.4.4/HLK for <[e-mail]>); Mon, 26 Jun 1995 21:56:29 -0400
Received: by apakabar.cc.columbia.edu id AA11097
  (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Mon, 26 Jun 1995 21:56:28 -0400
Path: news.columbia.edu!panix!bloom-beacon.mit.edu!news.kei.com!ddsw1!not-for-mail
From: [e-mail] (Leslie Mikesell)
Newsgroups: comp.dcom.modems,comp.protocols.kermit.misc
Subject: Re: Improved modem dialing for C-Kermit
Date: 26 Jun 1995 18:12:10 -0500
Organization: /usr/lib/news/organi[sz]ation
Lines: 60
Message-Id: <3snesa$[e-mail]>
References: <3seuml$[e-mail]> <3shhv6$[e-mail]> <3sl921$[e-mail]> <3sma6k$[e-mail]>
Nntp-Posting-Host: mars.mcs.com
Xref: news.columbia.edu comp.dcom.modems:99476 comp.protocols.kermit.misc:3051
Apparently-To: [e-mail]

In article <3sma6k$[e-mail]>,
Frank da Cruz <[e-mail]> wrote:
>>In my opinion you would be better off dropping hard-coded dialing
>>support completely.
>>
>I'd like to do that too, but when you begin to support non-Hayes
>compatibles, that you lose the ability to be totally table driven.  It's
>not only the commands that are different, it's also the very procedures
>themselves.  Nevertheless, C-Kermit's new features make it more
>table-driven, not less.

If you need features beyond expect-send sequences to dial, chances are
that someone will that feature outside the context of dialing too.
It should be included in the script command language, which in turn
makes dialing as a macro possible.

>>The Devices and Dialers files in HDB uucp provide a general solution
>>to these questions.  Rather than re-invent that solution or provide
>>less general hard-coded knowledge of specific devices that most people
>>don't have imbedded in every binary, why not duplicate it with some
>>macros in kermit and simply create the files for systems where they
>>don't already exist?

>But aren't we moving away from the timesharing world, where a bunch of
>users on the same machine are competing for the same pool of dialout
>ports?

Not entirely.  Many places have just put a PC on the desktop with
LAN connections to various resources.  In my case one of these is
a unix host with a bunch of modems doing dial in/out fax and data.

>An increasing proportion of C-Kermit users has total control of
>the computer they are using.

It is still moderately expensive to put an extra analog phone line
in everyone's office along with their digital multi-line sets that
don't work with modems, plus buying everyone their own modem.

>And when dialout ports are pooled, they are
>more likely to be on some kind of communication server that already
>handles this problem without the communications software needing to know a
>thing about it, e.g. reverse terminal servers where telnet'ing to port
>2000 gives you the first free dialout port.

That is probably the way to go, but the organizations that use kermit
aren't likely to be able to afford them.  In fact, I'd like to use
kermit to emulate one of them such that a PC kermit user would connect to
the unix host via telnet and the unix kermit would pick a modem line and
provide the connection as transparently as possible.  My real problem in
pursuing this at the moment is that I am replacing my AT&T servers
with an OSI transport that allowed MSDOS kermit to do a scripted login
to the unix hosts with a TCP/IP transport on the unix side and
WFW/winsock on the PC side and I haven't found a way to use kermit
with this setup.  Given that you can do this with a free server
(samba) and a cheap client (WFW w/TCP), I think this might be a popular
arrangement for people who would be likely to want to use kermit so
it is unfortunate that it doesn't work.

Les Mikesell
  [e-mail]